@GrahamcOfBorg build llvm_11 lld_11 clang_11

@DieGoldeneEnte this builds now for Darwin, but stopped working for Linux. I have no clue why.

libc++ failed,because it coudn't find python, it build normally once python3 is added as native build input.
Could this be, because the llvm-source is added as input?

I need to take another look, why it suddenly needs python...

Could this be, because the llvm-source is added as input?

Then it would fail on Darwin too, right?

Then it would fail on Darwin too, right?

That's my problem. I couldn't find a relevant difference between the working package in nixpkgs and this.
If I read it correctly, python is required when building libc++ standalone (I don't think we are setting LIBCXX_STANDALONE_BUILD, but python should only be needed if it is set) and using cmake > 3.12. Both should be given for the current nixpkgs derivation.

@DieGoldeneEnte on Darwin I get cmake-3.18.2 with nix-build -A cmake. Same on Linux?

@GrahamcOfBorg build lldb_11

@GrahamcOfBorg build llvmPackages_11

@DieGoldeneEnte Maybe the cmake machinery now runs some tests that require python3. I included Linux now, let's see what OfBorg says.

I just tried rebuilding the current master version of libcxx, but it is actually broken, because of the missing monorepo-layout :(
Is this the same problem as on darwin (before the changes here)?

Regarding LIBCXX_STANDALONE_BUILD, this is set by cmake (in libcxx/cmake/Modules/HandleOutOfTreeLLVM.cmake). So I don't think it should be set.
Reading the CMakeLists.txt file, it seems python is mandatory when building standalone (and cmake >3.12). I don't understand, why darwin doesn't need it, since the cmake code is (shortened):

if (LIBCXX_STANDALONE_BUILD)
  if(CMAKE_VERSION VERSION_LESS 3.12)
    [...]
  else()
    find_package(Python3 COMPONENTS Interpreter)
    if(NOT Python3_Interpreter_FOUND)
      find_package(Python2 COMPONENTS Interpreter REQUIRED)
      [...]
    endif()
  endif()
endif()

Are you building libc++ in a sandbox? Maybe cmake finds a python version from the system?

error:

libc++abi now requires being built in a monorepo layout with libcxx available

@DieGoldeneEnte I am debugging this right now. I'll trigger you after having done the fix.

shouldn't the test (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR) be true, because we run cmake in the libc++ directory. This would be false if the CMakeLists.txt file would be added via add_subdirectory/add_llvm_external_project (that's at least my understanding given my limited cmake knowledge).

@DieGoldeneEnte yes that test should be true. It is true. So this is a standalone build in a monorepo-layout source.
Darwin looks for a Python3 and doesn't find it. But on my machine it finds some Python2 in a framework, thus it can proceed. It would break in a sandbox.

I am making python3 mandatory now.

@DieGoldeneEnte things look good on my side!

@ggreif Why is the llvm source needed for libc++*? Is it to simulate the monorepo?
Builds without problems on my machine :)

@ggreif Why is the llvm source needed for libc++*? Is it to simulate the monorepo?

That's what I understand, too.

Builds without problems on my machine :)

THX! 🥇

LGTM then!

I think we will need to rewrite the llvm package since building the projects standalone is less and less supported.

Problem is with compilert-rt:

CMake Error at cmake/Modules/AddCompilerRT.cmake:318 (add_library):
  No SOURCES given to target: clang_rt.builtins-i686
Call Stack (most recent call first):
  lib/builtins/CMakeLists.txt:636 (add_compiler_rt_runtime)

fixed it (at least for i686) in my PR targeting this PR-branch.

@volth @DieGoldeneEnte but this is not a regression vs. 11.0.0rcs, right? Is it a regression vs. 10.0.1?

Anyway, better open a PR against those separately.

@ggreif It was introduced with 11.0.0-rc1, 10.0.1 does not have this change.